The databricks-protected-runner-group's egress firewall blocks TLS to
pypi.org and pypi-proxy.cloud.databricks.com (only files.pythonhosted.org
is reachable for TLS handshakes), which prevents uv from resolving
build-isolation deps like setuptools to compile thrift's sdist.

Other Databricks Python repos (e.g. databricks-ai-bridge) run their
pytest CI on plain ubuntu-latest with no proxy and it works fine.
Switch both jobs to match. The test job has no need for protected
egress, and e2e only uses secrets passed via env, which work the
same on either runner.

Also removes the now-unused UV_INDEX_URL env var and the temporary
network diagnostic step.

CI runners (e.g. GitHub Actions ubuntu-latest) set FORCE_COLOR=1, which
makes rich/typer render --help with SGR escapes that split styled tokens
across ANSI codes. ``"--agents" in result.output`` then fails because the
rendered output is actually ``--\x1b[0m\x1b[1magents``. The test passed
locally because non-TTY runs don't get colored.

Strip ANSI before checking so the assertion holds either way.

- ruff format: auto-formatted src/ucode/databricks.py (collapsed lines
  ruff now considers fitting under the 100-char limit).
- ty: typed the run() wrapper with @overload so text=True narrows to
  CompletedProcess[str] (every caller that reads the return value uses
  text=True). Also guard _scrub_json's dict-key match against non-str
  keys so re.Pattern[str].search gets a str.

Test suite stays at 535 passing.

The prior commit ran `git add -A` and swept up local-only scratch files
(.antigravitycli/, .claude/, .vscode/, OPENCODE_PLAN.md, mlflow.db,
scripts/) that should never have been tracked. Removing them from the
index — they remain on disk locally.

The Databricks CLI's `auth login --no-browser` fallback path reads stdin
for the user to paste an OAuth code. In CI the runner's stdin sometimes
keeps the subprocess alive past Python's timeout, hanging the whole job
for the full ~6h workflow limit. Redirecting stdin to /dev/null makes
that fallback EOF immediately, so if M2M env vars don't yield a token
we fail fast with a clear error instead of hanging.

Last CI run failed with `Databricks CLI returned no access token` after
get_databricks_token's pytest fixture couldn't authenticate via M2M env
vars. The CLI's stderr is captured (and discarded) by ucode so we never
see *why* M2M failed. This diagnostic step prints the CLI version, which
auth env vars are set, whether ~/.databrickscfg exists, and the raw
output of `databricks auth token` + `current-user me` so the next run
will tell us exactly what's wrong.

`databricks auth token` only returns cached user-OAuth tokens (from
`databricks auth login`) — it has no M2M path. Hosted-runner CI has no
~/.databrickscfg and no cached login, so the CLI command always errors
with "OAuth is not configured for this host", and ucode's token helper
hangs on the `auth login --no-browser` fallback waiting for stdin.

Teach has_valid_databricks_auth and get_databricks_token to short-circuit
to a pre-fetched DATABRICKS_BEARER env var (the same env var
build_auth_shell_command already honors). The e2e workflow pulls it from
a repo secret; user fetches a fresh bearer (e.g. M2M client_credentials
against /oidc/v1/token) and pastes it into Settings → Secrets when the
token expires (~1h).

Removes DATABRICKS_CLIENT_ID/_SECRET from the workflow — they're no longer
load-bearing now that we don't call the CLI for auth.

- tests/test_e2e.py: TestConfigureSubset patches `run_databricks_login`
  at the wrong module path. cli.py does `from ucode.databricks import
  run_databricks_login`, so patching `ucode.databricks.run_databricks_login`
  doesn't affect the local name cli uses, and the real function runs
  (which opens a browser). Patch `ucode.cli.run_databricks_login` instead.
- mcp_web_search.py: bump urllib timeout from 60s to 180s. Codex
  Responses API with native web_search does a real web fetch + LLM
  completion, which legitimately can exceed 60s under load.

The six TestXxxLaunch tests all call `_require_binary("...")` and skip
when the agent isn't on PATH. The runner has only Node.js, not the
agents themselves, so every launch test skipped. Install all six
via `npm install -g` so they exercise real binaries against the e2e
workspace.